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O ■ Abstract. The # component model was proposed to improve the practice ofpar- 

^ ■ allel programming. This paper introduces a type system for # programming 

systems, aiming to lift the abstraction and safety of programming for parallel 
d ! computing architectures by introducing a notion of abstract component based 

on universal and existential bounded quantification. Issues about the implemen- 
tation of such type system in HPE, a # programming system, are also discussed. 

(N 

1. Introduction 

Multi-core processors have already made parallel computing a mainstream technology, 
but high performance computing (HFC) applications that run on clusters and grids have 
Q \ already attracted the investments of the software industry. The key for reaching peak 

performance is the knowledge of how to apply HFC techniques for parallel programming 
by looking at the particular features of the parallel computing architecture. 

> 

CN \ With the raising of complexity and scale of HFC applications 

^ \ HFost and Votta 20031 . HFC developers now demands for software engineering 

cr^ ■ artifacts to develop HFC software USarkar et al. 20041 . Unfortunately, parallel pro- 

■ gramming is still hard to be incorporated into usual software development platforms 

O I HBemholdt D. E. et al. 20041 . Due to the success of component technologies in 

^ I the commercial scenario, component models and frameworks for HFC applications 

have been proposed Hvan der Steen 20061 . such as CCA and its compliant frame- 
works [[Armstrong et al. 2006|, Fractal/Fro Active IIBruneton et al. 200211 . and GCM 



X 



HBaude et al. 20081 . However, the HFC community still looks for a general notion of 



5^ I parallel component and better connectors for efficient parallel synchronization. 

The # component model was proposed to meet the aims of parallel software in 
HFC domain. It provides (#-)components with the ability to be deployed in a pool of 
computing nodes of a parallel execution platform and to address non-functional concerns. 
Based on a framework architecture recently proposed HCarvalho Junior et al. 20071 . a # 
programming system based on the notion of #-components was designed and prototyped, 
called HFE (The Hash Programming Environment). This paper presents the design of a 
type system for # programming systems, adopted in HFE, that support a suitable notion of 
abstract component for increasing the level of abstraction of parallel programming over 
particular architectures with minimal performance penalties. 

Section [2]presents the # component model and HFE. Section[3]outlines a language 
for describing configurations of #-components, whose type system is introduced in Section 
[Hand implemented Section[5l Section [6] concludes this paper, outlining further works. 
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Figure 1. From Processes to #-Components, Intuitively 



2. The # Component Model 

Notions of parallel components have been proposed in many computational frameworks 
for HPC applications Hvan der Steen 2006ll . In general, they lack the level of expressive- 



ness and efficiency of message passing libraries such as MPI [Dongarra et al. 1996 1. For 
this reason, the search for more expressive ways to express parallelism with components 
is at present an important research theme for people that work with CCA (Common Com- 
ponent Architecture), Fractal, and GCM (Grid Component Model) compliant component 
platforms IIAUan et al. 20021 IBaude et al. 20071 IBaduel etal.^OOTl . The # component 
model proposes a notion of components that are intrinsically parallel and shows how they 
can be combined to form new components and applications. 

A programming system is defined as any artifact for development of programs 
for applications in some domain. Examples of programming systems are programming 
languages, problem solving environments, computational frameworks, visual composi- 
tion languages, and so on. We say that a programming system is component-based if 
programs are constructed by gluing independent parts that represent some notion of com- 
ponent by means of a set of supported connectors. A component-based programming 
system complies to the # component model if they support the following features: 

• components are built from a set of parts, called units, each one supposed to be 
deployed in a node of a parallel computing execution platform; 

• components can be combined to form new components and applications by means 
of overlapping composition, a kind of hierarchical composition; 

• Each component belongs to one in a finite set of supported component kinds. 

Components of # programming systems are called #-components, which has 
been formally defined in previous works, using category theory and institutions 
HCarvalho Junior and Lins 200811 . Figure [H provides an intuitive notion of #-components 
by assuming the knowledge of the reader about the basic structure of parallel programs, as 
a set of processes communicating by message passing. For that, it is used a parallel pro- 
gram that calculate A x x • i3 x where A^xn and B^xk are matrices and x„xi and ytxi 



are vectors. For that, the parallel program is formed by processes coordinated in two 
groups, named p and q, with M and P processes, respectively. In Figure [B M = P = 2, 
p = {process 0, process 1} and q = {process 2, process 3}. In the first stage, the pro- 
cesses in p calculate v = Axx, while the processes in q calculate u = B xy, where Vmxi 
and Umxi are intermediate vectors. Figure[lja) illustrates the partitioning of matrices and 
vectors and the messages exchanged (arrows). M* denotes the upper rows of the matrix 
M, where M, denotes their lower rows. The definition is analogous for vectors, by taking 
them as matrices with a single column. Thus, the matrices A and B are partitioned by 
rows, while the vectors x and y are replicated across the processes in groups p and q. Af- 
ter the first stage, the elements of v and u are distributed across the processes in groups p 
and q, respectively. In the second stage, v and u are distributed across all the processes 
for improving data locality when calculating v •uin the third stage. 

In Figure [itb), the processes that form the parallel program described in the last 
paragraph are sliced according to software concern, whose definition vary broadly in 
the literature UMilli et al. 200411 . For the purposes of this paper, it is sufficient to take 
a concern as anything about the software that one wants to be able to reason about as 
a relatively well-defined entity. Software engineers classify concerns in functional and 
non-functional ones. In the parallel program of the example, the relevant concerns include 
synchronization, communication and computation operations and allocation of processes 
onto processors. Most of them involve the participation of slices of many processes, 
such as the four slices that define allocation of processes to processors, the two slices of 
processes 2 and 3 that perform the matrix- vector product U = B xY m parallel, and that 
ones defining communication channels {send and recv pairs). Such teams of cooperative 
slices define the units of #-components. In Figure [Ua), candidates to be #-components 
are represented by the dashed ellipses. Thus, a unit defines the role of a process with 
respect to the concern addressed by the #-component. The example also shows that #- 
components can deal with non-functional concerns, such as mapping of processes onto 
processors. The reader may be convinced that a # parallel programmer works at the 
perspective of concerns, while a common parallel programmer works at the perspective 
of processes. The resulting program may be viewed as a #-component that encapsulates 
the computation ofAxx»Bxy.\n such case, the processes, numbered from to 3, are 
their units. Notice that it is formed by combining units of the composed #-components, 
taken as slices of the resulting unit. This is possible due to overlapping composition. 



Why is # intrinsically parallel ? Usual component notions are sequential. In the sense 
of the # component model, they are formed by only one unit. In general, parallelism 
is obtained by orchestration of a set of components, each one executing in different 
nodes. Thus, a concern implemented in parallel must be scattered across the bound- 
aries of a set of components, breaking encapsulation and modularization principles be- 
hind the use of components. Another common approach is to take a component as a 
parallel program, where parallel synchronization is introspectively implemented inside 
the boundaries of the parallel component using some message passing interface like MPI 
[Dongarra et al. 1996 1. In such approach, the component platform is completely "out 
of the way" with communications between components and do not support hierarchical 
composition. Stronger parallelism approaches support parallelism by means of specific 
connectors for parallel synchronization, but losing flexibility and expressivity since pro- 
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Figure 2. HCL Abstract Syntax - Abstract (absConfig) and Concrete (concConfig) 



grammers are restricted to a specific set of connectors. The scattering of implementation 
of components in units and the support for connectors as (#-)components are the rea- 
sons to say that the # programming model is intrinsically targeted at the requirements of 
parallel computing for high-end HPC computer architectures. 

2.1. Component Kinds 

Usual component platforms define only one general kind of component, intended to ad- 
dress some functional concern, with a fixed set of connectors, taken as separate enti- 
ties in relation to components. The definition of component and the rules for compos- 
ing them to other components define the component model of a components platform 



[Wang and Qian 2005 1. It is attempted to define a notion of component that is general 
enough to serve for implementation of any concerns that could be encapsulated in a soft- 
ware module. # programming systems are distinct due to its support for many kinds of 
components, each one specialized to address specific kinds of concerns, functional or 
non-functional ones. We find the following main uses for components kinds: 

• connectors are taken as specific kinds of components, making possible for a pro- 
grammer to develop specific connectors for the use of their applications or libraries 
of connectors for reuse. This is an important feature in the context of HPC and 
parallel programming, where connectors must be tuned for the specific character- 
istics of the target parallel computer architecture. 

• component kinds can be used as an abstraction to define building blocks of appli- 
cations in specific domains of computational sciences and engineering, targeting 
specialists from these fields. In such case, component kinds and their composition 
rules could be viewed as a kind of DSL (Domain Specific Language). 

• In HPC context, to ensure interoperability in the implementation of existing 
component-based computational frameworks is considered a hard problem. We 
conjecture that interoperability among many # programming systems, specific and 
general purpose, may be obtained by developing of specific sets of component 
kinds only intended for supporting interoperability. 

2.2. HPE - A General Purpose # Programming System Targeting Clusters 

The Hash Programming Environment (HPE) is a # programming system 
based on a recently proposed architecture for frameworks from which pro- 



computation MATVEcPRODUCT(A'')(a, x, v) 

[T;Number,C: Arch i te c ture, 

E : Environment [c], Da : MatPart i t i on, 

Dx : VecPartition, Dv : VecPartition] 

begin 

iterator k from to A'^— 1 

data a : PDat A(iV) [Matri x[r], C, £, Da] 

data X : PDATA{A'")[VECTOR[r], C, E, Dx] 

data V : PDATA{A'")[VECTOR[r], C, E, Dv] 

unit calculate[k] 

begin 

slice aslice from a.m,atrix[k] 
slice xslice from x.vector[k] 
slice vsHce from v.vector[k] 
action . . . 
end 
end 



computation MatVecPro duct Imp lForDouble(A'') 
implements MatVecProduct(A'') 

[Double, GNUC luster, 
MPIFull[GNUCluster], ByRows, 
Re PLICATE, Re plicate] 

version 2.2.2.1 
begin 

iterator k from to A^— 1 

unit calculate[k] 

begin 

// source code in the host language 
end 
end 



Figure 3. Examples of HCL Programs (Full Syntax) 



gramming platforms targeting at specific application domains may be instan- 
tiated HCarvalho Junior et al. 2007ll . It is an open-source project hosted at 
http://code.google.eom/p/hash-programmin-environment. The HPE 
framework is implemented as a plug-in to the IBM Eclipse Platform, from which HPE 
is instantiated for general purpose parallel programming of HPC applications targeting 
clusters of multiprocessors. To fit this application domain, HPE supports seven kinds of 
components: computations, data structures, synchronizers, architectures, environments, 
applications, and qualifiers. The HPE architecture has three main components: 

• the Front-End, from which programmers build configurations of #-components 
and control their life cycle; 

• the Core, which manages a library of #-components distributed across a set of 
locations and provides configuration services; and 

• the Back-End, which manages the components infrastructure where #- 
components are deployed and the execution platforms where they execute. 

The interfaces between these three components were implemented as Web Services for 
promoting their independence, mainly regarding localization and development platform. 
For instance, from a Front-End a user may connect to any Core and/or Back-End 
of interest that can be discovered using UDDI services. The Back-End of HPE was 
implemented by extending the CLI/Mono platform, while the Front-End and the CORE 
were implemented in Java using the MVC (Model- View-Controller) design pattern. 

3. A Configuration Language for # Programming Systems 

Figure |2] presents the abstract syntax of an architecture description language (ADL) for 
overlapping composition of #-components, which could be adopted by a # programming 
system. This language is called HCL {Hash Configuration Language). HPE Front-End 
has implemented a visual variant of HCL. 

In previous papers, overlapping composition has been formalized 
using a calculus of terms, called HOCC {Hash Overlapping Composi- 
tion Calculus) HCarvalho Junior and Lins 20091 . and theory of institutions 
HCarvalho Junior and Lins 200811 . In this paper, HCL is adopted to provide a more 
intuitive description of overlapping composition, but keeping rigor. 



A configuration is a specification of a #-component, which may be abstract or 
concrete. Conceptually, in a #-programming system, a #-component is synthesized at 
compile-time or startup-time using the configuration information, by combining software 
parts whose nature depends on the component kind. A # programming system defines a 
function S for synthesizing #-components from configurations. S is applied recursively to 
the inner components of a configuration and combines the units of the inner components 
to build the units of the #-component. In HPE, units of a #-component are C# classes. 

Figure |3] present examples of configurations for abstract and concrete #- 
components, written in the concrete syntax of HCL, augmented with support for iterators. 
For simplicity, in the rest of the paper we refer to an abstract #-components as an abstract 
component, and we refer to a concrete #-component simply as a #-component. 

Conceptually, an abstract component fully specifies the concern addressed by all 
of its compliant #-components. Their parameter types, delimited by square brackets, 
determine the context of use for which their #-components must be specialized. For ex- 
ample, the abstract component MatVecProduct encompasses all #-components that 
implement a matrix-vector multiplication specialized for a given number type, execu- 
tion platform architecture, parallelism enabling environment, and partition strategies of 
the matrix a and vectors x and v. Such context is determined by the parameter type 
variables A^, C, E, Da, Dx, and Dv, respectively. For instance, the #-component spec- 
ified by MatVecProductImplForDouble is specialized for calculations with ma- 
trices and vectors of double precision float point numbers, using MPI for enabling par- 
allelism, targeting a GNU Linux cluster, and supposing that matrix a is partitioned by 
rows, and that elements of vectors x and v are replicated across processors. This is con- 
figured by supplying parameter type variables of MatVecProduct with appropriate 
abstract components that are subtypes of the bound associated to the supplied variable 
(e.g. Replicate <: VecPartition). 

In the body of a configuration, a set of inner components are declared, whose over- 
lapping composition form the component being configured. In MatVecProduct, they 
are identified by a, x, and v and typed by a reference to a configuration of abstract compo- 
nent with its context parameters supplied. Indeed, the inner component a is of kind data 
and it is obtained from the configuration PData when applied to the context parameters 
Matrix [A], C, E, and Da, which means that it is a parallel matrix of numbers of some 
configuration abstracted in the variable A, partitioned using the partitioning strategy de- 
fined by the variable Da, specialized for the execution platform C, and for the parallelism 
enabling environment E. These variables come from the enclosing configuration. 

The header of a configuration written in HCL also informs its kind and a set 
of component parameters, which are references to inner components defined as pub- 
lic ones. In fact, component parameters provide high-order features for #-components 
HAlt et al. 2004L In the example, all the inner components - a, x, and v - must be received 
as parameters by MatVecProduct compliant #-components in execution time. 

Finally, a configuration declares a non-empty set of units, formed hy folding units 
of inner components, called slices of the unit being declared. MatVecProduct has 
A units named calculate. Their slices define the local partitions of a, x, and v. In a 
well formed configuration, all units of any inner component are slices of some unit of the 
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Figure 4. Configuration Types 



abstract component being configured. A computation unit must also declare an action that 
specifies the operation to be performed. Recently, we have proposed the use of Circus 
for formal specification of these actions HCarvalho Junior and Lins 200911 . 

In MatVecProductImplForDouble, it is provided an implementation for 
the units of MatVecProduct, using the host language for programming units of #- 
components of kind computation. In HPE, computations, as well the other kinds of 
components, are programmed in any language that has support in the CLI/Mono plat- 
form. The HPE system partially generate the code of units of abstract components and 
#-components, using the translation schema that will be presented in Section [5l 

4. A Type System for # Programming Systems 

Figure in presents a syntax for types of configurations of #-components, whose associated 
subtyping relation is presented in Figure [5l The production 4.1 states that a configuration 
may be typed as an abstract component type or a #-component type. Also, it defines that 
there is a top abstract component associated to each kind. Abstract component types are 
defined in 4.2. The set of bound variables Xi, . . . , X„ denote their context. An abstract 
component type also specifies a shape, describing how it forms an abstract component 
from overlapping composition of other #-components. The shape of an abstract compo- 
nent type is defined in 4.3. The general form of #-component types is defined in 4.4, from 
an abstract component type by supplying their bound context variables. 

In the shape of a #-component (Figure lU, k specifies its kind, among the kinds 
supported by the # programming system. The labels ai, . . . , a; identify inner compo- 
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Figure 5. Subtyping Rules 



kind C [Xi : Ti •--'■■■"](ai '-i- -") 
begin 

kindi a,- : (7,- (a^. . J = l- -Pi) '=!■ 
I > • ^ ^zj ' 

unit ^ ■ ^ 

begin 

slice Sfj from ■ ■ .v^j . - .m^ 

action 

end 
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begin Body end 
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begin Body end 



< \r{Vi,T) ■= 
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begin 

kind; ai : (a^ ■ ■ 
unit It. ^ 
begin 

slice Sjj from a 

action 

end 

end 



(«i ) 
j = l.,.pi ^ i = l.. 
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begin 

unit Ui ^ '"^ 
begin 

slice Sij from 

action 

end 



= l...Pi^ i = l.. 
= l..-p. . i = fc4 



r(x, r) - 
(5.4) 



kind C [Xi : ^--^■-■"■] 

implements C [X^ 
begin 

unit ^=1---Q 
begin 
Si 

end 

end 



(5.5) 



[vi,r 



Figure 6. Schema T for Computing the Type of a Configuration (Outline) 



nents, with their associated #-component types. The inner components labeled from 
ai to ttfc are the public ones (component parameters of a configuration). The assertions 
uf {ai, Li) *=i - '? type the units of the #-component. For any unit, the function a maps a 
set of symbols that denote labels of slices to units of inner components, denoted by a.u, 
where a e {ai, . . . ,ai} and is a label of a unit of the inner component labeled by a. 
The typing rules for configurations impose that each unit of an inner component must 
be a slice of one, and only one, unit of the #-component. L is a formal language on the 
alphabet Dom(cr), denoting the tracing semantics that defines the action of the unit. 

In Figure [6l it is outlined T, a function for calculating the type of a configura- 
tion. The auxiliary parameter T is the set of bound variables, often known as context. It 
ensures that any variable referred in a configuration is declared in the header. No free 
variables exist in a well formed configuration. T, U, and V denote logical variables in 
the definition for references to configurations of #-components. The definition 5.1 types 
the configuration of an abstract component. The definition 5.2 types a configuration of 
abstract component applied to an actual context, where the resulting type is the type of 
the #-component that may be applied in the context. The definition 5.3 types an abstract 



procedure findHashComponent 
sort(CTOP); 

tryGeneraIize(aext of CTOP); 
if (cTOP has implementation) 

then return implementation of CTop 

else fail ! 
end-if 
end-procedure 

lastMarked = null; 
procedure sort(C): 

if C has unmarked parameters 
for each unmarked parameter d of C 
sort(Ci) 

else 

mark(C); 

next of C = lastMarked; 
lastMarked = C; 
end-if 
end-procedure 



assumption: let k be the kind of CTOP. 

procedure tryGenemlize(C) 

if C=null or CTOP has not an implementation in e 
reset C ; 
C' = C; 
repeat 

replace C by C 
tryGeneralize(next of C) 
C' «— least proper supertype of C; 
until C" == Top^ or CTOP has an implementation in e; 
end-if 
end-procedure 



CTOP is a #-component type. Thus, it has form H, such that H = cid [Ci, C2, ■ ■ ■ , Cn], where cid is a reference to a configuration of 
abstract component and each d is a context parameter of the form H, recursively. The resolution algorithm tries to find a #-component 
that types to CTOP in an environment e of deployed #-components maintained by the # programming system. The algorithm has two 
phases, defined by the procedures sort and tiyGeneralize. The first one calculates a total order for traversing the recursive context 
parameters of CTOP, by calculating the relation "next of". Procedure tiyGeneralize recursively traverse this list, calculating the least 
proper supertype of each parameter in e and testing if the cun'ent generalized type has some implementation in the environment e. If 
anyone is found, the procedure returns it. The operation "replace C by C'" replaces, in CTOP, the parameter C by its least supertype 
C' in €, while "reset C" sets C back to the initial parameter, after successive generalizations. The algorithm always stop, since 
there is a finite number of parameters in an abstract component and each kind k of abstract component has a maximum supertype 
(Top^). Also, the algorithm is deterministic, because each abstract component has only one supertype (by single inheritance) and 
each abstract component has only one #-component that conforms to it in the context (by singleton design pattern). 

Figure 7. Deterministic Traversing of Subtypes of Abstract Components 

component with public inner components supplied, which is necessary to define the type 
of inner components in the definition 5.1. The definition 5.4 only maps configuration vari- 
ables to type variables, provided that they exist in the context. The definition 5.5 types a 
configuration of a #-component. For simplicity, the definition ignores extends clauses of 
configurations (definition by inheritance). 

4.1. Interpretation 

Abstract and concrete components may be interpreted in terms of the combinators of an 
usual type system with universal and existential bounded quantification and type opera- 
tors. Let C be an abstract component type C = [Z <: Ti] > T2. Its interpretation, C-^ 
may be defined like below: 

= XX<:Ti. Vr<:X {3Z<:Ti; T2}, 

where variables X and Y are not referenced in T2 {{X,Y} fl Vars{T2) = 0). 
Moreover, a #-component 

kind c [Y:T^] implements C [Y] begin . . . end 

has the following interpretation: 

= XY<:T,. {{*Y; t} as {3Z<:T,; T2}) 
Notice that has type [T3I1]. 
'Using the notation of IPierce 200211 . C-^ is a type operator, with parameter type X bounded by Ti. 



As discussed before, the declaration of an inner component of abstract component 
type C makes explicit the definition of the intended context in the supplied parameters of 
C. For instance, suppose that c is dynamically linked by the execution environment for 
supplying the inner component labeled a, defined as 

kind a : C [T3]. 

Of course, T3 <: T3. Thus, T3 is now the representation type in c, which has been 
generically defined as X, such that X<:T^. In terms of the interpretation, it is applied the 
package T3 in the context. All operations inside c will be defined in relation to T3 and 
not in relation to T3, the upper bound of the abstract representation type X. 

More intuitively, C includes #-components that are best tuned to be applied in a 
context where a subtype of Ti is used, abstracted in type variable operator X. In partic- 
ular, the previous context, for inner component a, requires T3. Thus, any #-component 
belonging to C that is best tuned for some supertype of T3 and subtype of Ti, may be 
dynamically bound to a, such as c, which best tuned for T3, since Ti^<:T3<:Ti. 

The previous discussion may be trivially generalized for many parameters. 

For improving understanding, let 

synchronizer CHANNEL [£':Environment, D:Data] 
begin 

unit send 

unit recti 

end 

be a configuration of an abstract component whose #-components represent com- 
munication channels that may be tuned for a specific parallelism enabling environment 
(middleware or library) and data type to be transmitted. A configuration may demand for 

synchronizer ch : CHANNEL [MPIFULL , VECTOR] 

, where ch must be dynamically bound to the best communication channel available in 
the environment that can transmit an array in an execution platform where full MPI 
is available (any #-component package whose type is a subtype of T(Channel) < 
[MPIFULL, Vector]). By the subtying rules, #-components with the following con- 
figuration headers may be bound to ch: 

1. synchronizer ChannelImplI [£':MPIFull, D: Vector] implements Channel [E,D] 

2. synchronizer ChannelImpl2 [£;:MPIBasic, Z):Vector] implements Channel [E, D] 

3. synchronizer ChannelImpl3 [£;:MPIFull, D-.Data] implements CHANNEL [E, D] 

4. synchronizer ChannelImpl4 [£':MPIBasic, DiData] implements Channel [E,D] 

The first one is the better tuned one for the context where T(Channel) < 
[MPIFULL, Vector] is demanded. The other ones are approximations. By looking at 
the fourth case, notice that a channel that use the basic subset of MPI primitives and that 
can transmit any data structure, including arrays, can be applied in the context. In fact. 

Thus, the type C^[U], for a given U<:Ti, is universally quantified (polymorphism) in the variable Y. A 
#-component applied to V icp- V), typed as C-^[U], where V<:U, returns a package of existential type 
{3Z<:Ti; T2} with an abstract representation type bounded by V, which is safe since V<:U<:ri. 



AppExampleAbs [C, E[C], N, Sa, Sx, Sv, Sr] 
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Figure 8. Hierarchy of Components of the Application Example 



if the system does not find a better tuned #-component, it will traverse subtypes, deter- 
ministically, using the algorithm described in Figure Ul to find a the best approximation 
available in the environment of deployed #-components. In the example, by supposing 
that MPIFULL directly extends MPIBasic and that Vector directly extends Data, the 
types will be traversed in the presented order. To be deterministic, the so called resolu- 
tion algorithm supposes that the # programming system supports a nominal and single 
inheritance subtyping system. In fact, both restrictions are supported by HCL. 

5. Implementation Issues 

This section shows how the proposed type system has been implemented in HPE, the 
# programming system introduced in Section I2.2[ The Back-End of HPE treats a #- 
component as a set of CLI/Mono object, each one associated to a unit, instantiated from 
a C# class. Therefore, the function S map configurations of abstract components to C# 
interfaces and configurations of #-components to C# classes that implement the interface 
associated to the configuration of the abstract component that it implements. 

kind C [Xi : Ti '=i---"] (a^ 
begin 

kindi ai : U, (a,,^. ^=i--P.) '=i--' 
unit Ui '=i- -9 
begin 



Let C 



slice fromaz^yVij J— 
action Ai 



end 



end 



be a configuration schema of an ab- 



stract component. S(C) maps to a tuple of C# interfaces, one for each unit Ui, with the 



structun 



namespace C 
{ 

public interface I"^ (X> : I*""* 
[ where Xj : t^i-^ii 

{ 



a slice Tj .Wij exists (transitively) in Ui 



j = l...n 



I^'M-''-^ {set;}; 



j = l...mi 



Note about notation: 



A,, 



means a sequence that include the elements Ai, for i G 



{1, . . . , n}, such that predicate Pi is valid. 



The index i refers to the unit (ui). The interface declares a set of properties Sij, 
one for each slice of the unit that corresponds to a unit of a public inner component. They 
require only their set access method. The reason will be clarified in the next paragraphs. 



The notation used for abstracting C# interface identifiers, J^^ij-^'^ means the name of the 
C# interface that correspond to the unit Vij of the configuration f/^. . 



Let cimpi : 



?' — 1 . . . 77 . j 

implements C" [Xi '=1 ••"] 



kind C [Xi : Ti 



be a configuration of a #-component. 



begin 

unit Ui '=^---'i 
begin 

C, 

end 

. end 

S{CImpl) maps to a set of C# classes, one for each unit Ui, with the following structure: 

namespace CIrnpl 
{ 

public class H"' (x) : Unit, CI"' (x) 

where Xj : l^j-^ii 



{ 



a slice Tj .Wij exists (transitively) in Ui 



j = l...ni 



// private slices 

private I'^^^j'"'^ - null; 

private I »J ' Sij 

{ 

set { 

Si^ = value; 



^ik-S'iji, = value; a^^^. is a parameter of 



Zij e 



,1} 



j — l...mi 



// public slices 

private 1 s 
public l^'^i-"-^ S. 
{ 



null; 



set { 



Sij = value; 

^ik-S'ijk = value; 



} 



az^^ is a parameter of a^^ 



Zij G {1, . . . , fc} 



j = l...mi 



// creation of private slices 

public void createSlices ( ) 
{ 

base . createSlices ( ) ; 



this . Si' 



3ackEnd . createSlice (this , . . . ) ; 



Zij G {k+l,...,l} 



j — l...mi 



Ci // kind dependent part 



} 



The properties associated to the public slices of unit Ui, named 
S'jj ' required by interface C.P% are implemented. In addition, 
there are private properties for the private slices of Ui, named Sij li6{i,...,mi}Az,j G{fc+i,...,«} 

The public method createSlices and the static method BackEnd. createSlice 
form a mutually recursive pair. When creating a unit Ui of a #-component c, createSlices 
calls BackEnd. createSlice to create the unit of some private inner component az^j 
of c that is a private slice Sij of Ui. Then, after instantiating Vij, BackEnd. createSlice 



calls createSlices for creating its slices. The procedure proceeds recursively until units 
with no slices are reached (primitive units). In the return, the object that represents Vij 
is assigned to the slice property Sij, causing a call of its writing access method (set). If 
a^.^ supplies any public inner component of another inner component a^.^., then Vij is also 
assigned to the corresponding public slice S-^^ of Sik, such that Sik^a^.^.v^, E a-i. 

Moreover, BackEnd.createSlice is a parallel method, since q simultaneous calls 
are performed to create a #-component c, each one executed by a process that has a unit 
Ui *=i- -9 as slice. The i*'' call queries the DGAC (Distributed Global Assembly Cache), 
the HPE module responsible to manage parallel components, to find the class H"' that 
represent the unit Ui of the best #-component, deployed in the environment, for the ab- 
stract component referred by the inner component in the configuration. For that, DGAC 
uses the resolution algorithm of Figure |71 

For each kind of #-component, it may be defined a dependent part, referred as Cj 
in the schema. More specifically, Cj is the implementation of the interface defined by the 
interface I^""^. For example, for the kind computation, of HPE, it is defined the interface 

interface IComputation { 
void compute 0; , 

} 

whose method compute is implemented by the programmer to define the compu- 
tation to be performed over the slices of each unit. 

5.1. Case Study 

Figure[8]depicts the hierarchy of components of a configuration of an abstract component 
of kind application for the parallel program of Section[2l named AppExampleAbs. The 
ellipses represent the transitive inner components that appear in the overall application. 
The arrows represent the "is inner component of" relation. The colors assigned to the 
abstract components distinguish their kinds. Dashed ellipses indicate parameters of the 
configuration, whose associated variable identifiers are italicized. 

The configuration of the inner component V = A x X is M AtVecProduct, dis- 
cussed in Section |3l To illustrate how the proposed type system fits CTS (Common 
Type System), of CLI virtual machines, the interface I Calculate, associated with 
the units of the abstract component MatVecProduct, and the class HC a leu late, 
associated with the units of MatVecProductlmplForNumbers, are presented in Fig- 
ure m obtained from the translation schemas introduced in the beginning of Section [51 
MatVecProductlmplForNumber differs from MatVecProductlmplForDouble because 
it works with any number data type, including double precision float point ones. 

It is important to understand how generic types of CLI are used to implement 
the relation between abstract components and their #-components. For instance, the 
interface I Calculate is generic in type variables C, E, N, Sa, Sx, and Sv, like 
MatVecProduct. HCalculate is also generic in the same type parameters, but their 
bounds are specialized for the types for which the class is tuned, making possible to make 
assumptions about the structure of objects of these types. In the method compute of 
HCalculate (lines 22 to 34), it is shown that CTS does not allow that one instantiates 
an object of class INumberlmpl, implementing INumber, in a context where a object 
of type N, such that N <: INumber, is expected, like in line 27 (1st attempt). If the 



01. namespace example.computation.MATVECPRODUCT 

02. { 

03. public interface ICa!culale<C, E, N, Da, Dx, Dv> 
04 : ICompulationKind 

05. where C: ICluster 

06. where E: lEnvimnuient 

07. where N: INumber 

08. where Da: IVecPartition 

09. where Dx: IVecParfifion 

10. where Dv: IVecPartition 



11. { 

12. EEnv{sct;} 

13. IParDataKC, E, Matrix<N>, Da> A {set;} 

14. IParDataKC, E, Vector<N>, Dx> X {set;} 

15. IParDataKC, E, V<'cfDj-<N>, Dv> V {set;} 

16. } 

17. } 




Figure 9. Unit of IUIatVecProduct and lUlatVecProductlmplForNumber 



value of at run-time is a proper subtype of INumber, like IDouble, the assignment 
to array elements in line 32 is unsafe. On the other hand, if the variable newValue is in- 
stantiated like in line 30 (2nd attempt) it is created an object of the actual type of N, which 
can be IDouble safely. This is the reason why languages such as C# and Java only sup- 
port invariant generic types {T{U) <: T'{U') ^ T <: T' AU = U'). In languages like 
Java, where generic types are implemented using type erasure, it is not possible to create 
an instance of the class associated to type variable at run-time, since type variables are 
erased in compilation. But this is possible in C#, using reflection, because the bytecode 
of CIL (Common Intermediate Language) carries generic types at runtime. This is one of 
the motivations to use Mono for implementing HPE. 

6. Conclusions and Lines for Further Works 

The # component model attempts to converge software engineering techniques and par- 
allel programming artifacts, addressing the raising in complexity and scale of recent ap- 
plications in HPC domains. The recent design and prototype of HPE, a # programming 
system, suggests gains in abstraction and modularity, without significant performance 
penalties. This paper introduced a type system for # programming systems that was ap- 
plied to HPE, allowing the study of its formal properties, mainly regarding safety, com- 
positionability, and expressiveness. It has been designed for allowing programmers to 
make assumptions about specific features of parallel computing architectures, but also 
providing the ability to work at some desired level of abstraction. This is possible due to 
a combination of existential and universal bounded quantification. In the near future, it is 
planned to research on the how other concepts found in higher-level type system designs 
may improve parallel programming practice. 
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